Lecture 5
Next-up
Joon Yoo
October 5, 2018
Multimedia: video
▪ video: sequence of images displayed at
constant rate
• e.g., 24 images/sec
▪ digital image: array of pixels
• each pixel represented by bits
▪ coding: use redundancy within and
between images to decrease # bits
used to encode image
• spatial (within image)
• temporal (from one image to next)
- 2
……………………..
spatial coding example: instead
of sending N values of same
color (all purple), send only two
values: color value (purple) and
number of repeated values (N)
……………….…….
frame i
frame i+1
temporal coding example:
instead of sending
complete frame at i+1,
send only differences from
frame i
Streaming stored video:
▪ simple scenario:
- 3
video server
(stored video)
client
Internet
❖streaming stored audio, video
▪ streaming: can begin playout before downloading entire file
▪ stored (at server): can transmit faster than audio/video will be rendered (implies
storing/buffering at client)
▪ e.g., YouTube, NetFlix, Vimeo, …
Streaming multimedia: HTTP
▪ multimedia file retrieved via HTTP GET (Same as Web!)
▪ send at maximum possible rate under TCP
▪ Buffer fill rate fluctuates due to TCP congestion control, retransmissions (in-order delivery)
▪ Use application playout buffer: larger playout delay - smooth application playout
▪ Examples: Youtube, Netflix, and most streaming applications…
- 4
variable
rate, x(t)
TCP send
buffer
video
file
TCP receive
buffer
application
playout buffer
server
client
Why HTTP (TCP)?
▪ UDP vs. TCP
• UDP: unreliable (no acks), lightweight (faster), smooth
• TCP: reliable (use acks), heavyweight (slower), sawtooth pattern (congestion control)
▪ UDP was used mainly for multimedia streaming
• But UDP traffic is blocked at firewalls – security issue
• Need separate servers for Video streaming
▪ Why HTTP (TCP)?
• HTTP/TCP passes more easily through firewalls (UDP cannot)
• Can utilize existing Web servers (can be used for both Web and Video streaming)
• TCP sawtooth pattern can be smoothened by application buffer
- 5
DASH: Dynamic, Adaptive Streaming over HTTP
▪ server:
• divides video file into multiple chunks
each chunk is 1~15 seconds of video data
• each chunk stored, encoded at different rates
▪ client:
• periodically measures server-to-client bandwidth
• chooses maximum coding rate sustainable given current bandwidth
• can choose different coding rates at different points in time (depending on
available bandwidth at time)
▪ Examples: MPEG-DASH, Adobe, Apple, MS, …
- 6
720p
360p
240p
Next-up
▪ MP-DASH: Adaptive Video Streaming Over Preference-Aware Multipath,
CoNEXT'16
• Multipath TCP + DASH = MP-DASH
• Main Goal: Enhance MPTCP to support adaptive video streaming (DASH)
• Example: Use less cellular data (=less money) with negligible degradation of QoE
Motivations
▪ Multipath TCP
• Path selection in MPTCP is defined by MPTCP scheduler: select the smallest RTT path
▪ Measurement Study in the Wild
• Can Wi-Fi alone support 1080p video? → 3 scenarios:
1) Wi-Fi only is never able to support 1080p (64%)
2) Wi-Fi can sometimes play 1080p, but not always (15%)
3) Wi-Fi can almost always stably support 1080p (21%)
• 79% of the time Wi-Fi is poor: Wi-Fi alone cannot always support 1080p
MPTCP can be helpful... increases throughput – better QoE!
• 21% of time Wi-Fi alone is enough (next slide)
Motivations
• 21% of time Wi-Fi alone is enough (continued)
MPTCP can use unnecessary use LTE bandwidth
Example: 1080p needs 4Mbps, current Wi-Fi 12.1Mbps,
LTE 14.6Mbps – MPTCP still uses LTE!
▪ Controlled Experiments
• Observation 1: LTE link is almost always used even
though we need only 0.2Mbps LTE for 1080p
• Observation 2: After finishing downloading a chunk,
networks will be idle. This means enough video
chunks in receiver buffer.
QoE will not be affected if chunks arrive a bit late, as long
as playback deadline is met
